Subject: Flow Control Issues

From: Robin Layland <[email-masked]>
Date: Mon, 19 Jul 93 01:33 GMT

Robin Layland........
On the Circuit/Connection issue. I would like us to use the same term as the DLW
document is going to use. I agree that DLS didn't use the best of term but I
understand that Circuit is the connection between router (not end stations to
end station (or end station to DLSw to DLSw to end station). Connection is the
end to end session. Could we get a ruling from someone who know the RFC and then
stay will those term (and not change the terms unless the entire SIG agrees). 
 
On the issues of flooding the network with RNR (2*connection) if a circuit has
problem. While the number could be large the RNR are going out over a LAN, which
has high capacity. If the receiving DLSw has problem, it sends a message back to
the origining Router about the Circuit (only one message per circuit).  I fell
the N*connection is acceptable. Trying to decide which sessions (connections) in
a curcuit to RNR and which ones not to would require a priority scheme within
the curcuit which we don't have. May be nice to have one but let try to finish
the first round and then talk about adding it.
 
The issue of LLC1 traffic is interesting. First it applies primarily to Netbios
traffic but can be important since Netbios traffic could use the same circuit
that SNA traffic uses. Thus the SNA traffic would receive RNRs but the LLC1
Netbios traffic would kept on being sent. There is no easy way out. First the
router must tell every connection(session) on a circuit to halt using RNR. The
router could then queue so traffic but when the queues are full, it must discard
any additional traffic. The hope is that the LLC2 traffic would stop because of
the RNRs and the router would just discard all the new LLC1 traffic. This has
the negative side of requiring the router to process the LLC1 traffic but there
is no other means to stop the LLC1 traffic. The hope (again) is that the LLC1
traffic would slow down due to error recovery. The LLC1 would have a good chance
of timing out if none of its traffic got through during error recovery. The
result may be when there is a long period of congestion, that the LLC2 session
wait and the LLC1 session time out and are drop at the sending device. This is
not a perfect world but what more can we do. Remember, if you are using LLC1 you
don't expect the network at the DLC level to be reliable. Also, if this is a
problem then the answer is to fix the capacity problem (routers can't solve all
the problems).
 
My conclusion on the LLC1 issue: RNR the LLC2, drop all the messages after the
queues for a circuit fill up. How big the queues are for each circuit is an
implementation issues. (I think I understand that the queues for each circuit
are separate, if not they should be).
 
Robin Layland

---

From: [email-masked] (S B)
Date: Mon, 19 Jul 1993 17:11:17 -0400 (EDT)

In response to Robin's comments, I agree that we have to punt the LLC1
issues.  Because LLC1 is essentially stateless there is no mechanism
that all of the end stations out there would recognize as a graceful 
flow control mechanism.  I imagine that congested boxes would drop
the LLC1 frames at any stage in the processing.  Once LLC2 frames are
accepted into the state machine, they cannot be dropped.  Instead
they are added to queues that fill up and trigger the flow control
actions.

> stay will those term (and not change the terms unless the entire SIG agrees). 

My take on the terminology is opposite of what Robin said.  The RFC defines
and end-to-end CIRCUIT as defined by a pair of "Circuit IDs".  Each circuit
ID is a combination of port ID and DLC correlator.  This uniquely defines an
end station/end station LLC2 connection. The RFC then briefly talks about TCP 
CONNECTIONS between switches but I don't think it necessary gives them
a name.  A DATA LINK is also an end to end connection, but only through LLC1
type operation. 

> the first round and then talk about adding it.

I will try to address this issue with my idea of the terminlogy, but I'm
not sure how it will end up or if I have misunderstood the question given
the difference in terminology. Are we trying to manage the remote end
of a TCP connection through messages across TCP?  I think that watching
the outbound TCP windows and queues would be enough to know that the
far side DLS can still receive frames. If the TCP queues fill up, we RNR 
local LLC2 sessions that use the TCP connections. Can you still send data
if you issue an RNR?  We can then use the pacing flow control for the
end-to-end circuit flow control, with possibly the ENTERBUSY/EXITBUSY
SSP messages for the drastic cases.  

Scott

---

From: [email-masked] (David Matusow)
Date: Wed, 11 Aug 93 12:03:42 -0400

>   From: [email-masked] (Anand Subramaniam)
>   Subject: Flow Control Issues
>   To: [email-masked] (Flow Control in DLSw)
>   Date: Tue, 10 Aug 93 11:06:07 PDT
>   Organization: Novell Inc., 2180, Fortune Dr.,San Jose, CA 95131. USA
>   Group: Protocols, Software Engineering 
>   Local-Phone: (408)-473-8413
>   X-Mailer: ELM [version 2.2 PL15]
>   
>   
>   Hi,
>   
>   If the proposed pacing scheme were to work well, we need to figure out a way
>   by which the the IPM could be delivered to the peer without the possibility
>   of a closed TCP send window. One way to do that is to ensure that the
>   receiving TCP always has receive window open. The other way is to have a
>   "control channel" which is used to send only control messages.
>   

some systems fix a buffer or 2 that cannot be filled with anything BUT
these types of flowcontrol requests/responses.  This ensures that you
don'g get into a deadly embrace waiting for flow control because of 
a buffer shortage, but can't send it out or can't take it in BECAUSE
of the buffer shortage.  As these requests/responses are short in nature,
the size of the buffer held is not of major consequence.

David Matusow
Hypercom, Inc.